src/main/java/stackpot/stackpot/feed/service/FeedQueryServiceImpl.java (2)

209-218: saveCount N+1 쿼리 가능성 → 배치 조회로 최적화

현재 각 피드마다 countByFeed(…)를 호출해 저장 수를 세고 있어 N+1 쿼리가 발생할 수 있습니다. 아래와 같이 한 번에 집계 후 map으로 활용하는 방식을 추천합니다(이미 getLikedFeedsWithPaging에서 유사 패턴 사용 중).

예시:

List<Long> feedIds = feeds.stream().map(Feed::getFeedId).toList();
Map<Long, Integer> saveCountMap = feedSaveRepository.countSavesByFeedIds(feedIds).stream()
        .collect(Collectors.toMap(
            row -> (Long) row[0],
            row -> ((Long) row[1]).intValue()
        ));

List<FeedResponseDto.FeedDto> feedDtos = feeds.stream()
    .map(feed -> {
        int saveCount = saveCountMap.getOrDefault(feed.getFeedId(), 0);
        // ...
    }).toList();

Also applies to: 247-256

---

183-233: 커서 기반 페이징 보완 필요: UserMyPageResponseDto에 nextCursor 미포함

getFeedsByUserId/getFeeds 메서드는 cursor 파라미터를 받아 다음 페이지 커서를 계산하지만, 반환 DTO인 UserMyPageResponseDto에 nextCursor 필드가 없어 프론트에서 무한 스크롤 대비가 불완전합니다. 다른 페이징 응답(CursorPageResponse, FeedPreviewList 등)에서는 nextCursor를 포함하고 있으니 일관성 있게 추가해주세요.

점검 위치

• src/main/java/stackpot/stackpot/feed/service/FeedQueryServiceImpl.java
  • getFeedsByUserId(Long userId, Long nextCursor, int pageSize)
  • getFeeds(Long nextCursor, int pageSize)
• src/main/java/stackpot/stackpot/user/controller/UserController.java
  • getFeedsByUserId (Line 414–426)
  • getFeeds (Line 437–443)

개선 제안

1. UserMyPageResponseDto에 Long nextCursor 필드 추가
2. 서비스 레이어에서 feeds 조회 후 다음 커서 계산

   Long nextCursorVal = (feedList.size() >= pageSize)
           ? feedList.get(feedList.size() - 1).getFeedId()
           : null;

3. DTO 빌더에 반영

   @Builder
   public class UserMyPageResponseDto {
       private Long id;
       private List<String> seriesComments;
       private List<FeedResponseDto.FeedDto> feeds;
       private Long nextCursor; // 추가
   }

위 변경을 통해 프런트에서 안정적인 커서 페이징을 보장할 수 있습니다.

src/main/java/stackpot/stackpot/user/converter/UserMypageConverter.java (1)

51-57: N+1 쿼리 및 contains 성능 이슈

1. feedSaveRepository.countByFeed(feed) 호출이 피드 수만큼 반복되어 N+1 쿼리가 발생합니다.
   SearchServiceImpl에서 이미 존재하는 countByFeedIds(...) 배치 메서드를 활용해 주세요.
2. likedFeedIds / savedFeedIds가 List이므로 contains가 O(n)입니다. Set으로 변환하면 O(1)로 개선됩니다.

예시 diff:

-List<Long> likedFeedIds = feedLikeRepository.findFeedIdsByUserId(user.getId());
-List<Long> savedFeedIds = feedSaveRepository.findFeedIdsByUserId(user.getId());
+Set<Long> likedFeedIds = new HashSet<>(feedLikeRepository.findFeedIdsByUserId(user.getId()));
+Set<Long> savedFeedIds = new HashSet<>(feedSaveRepository.findFeedIdsByUserId(user.getId()));

- int saveCount = feedSaveRepository.countByFeed(feed);
+ int saveCount = feedSaveCountMap.getOrDefault(feed.getFeedId(), 0);

src/main/java/stackpot/stackpot/save/repository/FeedSaveRepository.java (2)

13-13: 와일드카드 임포트 지양 권장

java.util.* 대신 필요한 타입만 임포트하면 가독성과 정적 분석 신뢰도가 올라갑니다.

---

40-47: 카운트 캐스팅 안정성 보강 제안

Hibernate/JPA의 COUNT 결과는 Long이 일반적이지만, 구현체/설정에 따라 Number로 반환될 수 있습니다. 안전하게 캐스팅하면 ClassCastException 가능성을 낮출 수 있습니다.

다음 변경을 권장합니다:

-        for (Object[] row : countByFeedIdsRaw(feedIds)) {
-            map.put((Long) row[0], (Long) row[1]);
-        }
+        for (Object[] row : countByFeedIdsRaw(feedIds)) {
+            Long feedId = (Long) row[0];
+            Long cnt = ((Number) row[1]).longValue();
+            map.put(feedId, cnt);
+        }

또는 DTO 프로젝션을 사용하면 캐스팅 자체를 없앨 수 있습니다.

src/main/java/stackpot/stackpot/pot/converter/PotApplicationConverter.java (1)

48-49: 닉네임 접미사 하드코딩 제거 및 공통화 제안

" 새싹" 접미사가 여러 컨버터에 하드코딩되어 있어 변경 시 누락 위험이 큽니다. 상수/유틸로 공통화하세요.

예시:

• 공통 상수 정의

// 예: stackpot.stackpot.common.display.UserDisplayConstants
public final class UserDisplayConstants {
    private UserDisplayConstants() {}
    public static final String NICKNAME_SUFFIX = " 새싹";
}

• 본 파일 적용

-                .userNickname(entity.getUser().getNickname() + " 새싹")
+                .userNickname(entity.getUser().getNickname() + UserDisplayConstants.NICKNAME_SUFFIX)

src/main/java/stackpot/stackpot/pot/converter/PotDetailConverter.java (2)

43-44: 닉네임 접미사 공통화 권장

여기서도 " 새싹"이 하드코딩되어 있습니다. 공통 상수/유틸을 도입해 일관되게 사용해 주세요.

-                .userNickname(user.getNickname() + " 새싹")
+                .userNickname(user.getNickname() + UserDisplayConstants.NICKNAME_SUFFIX)

---

49-59: 중복 필드 설정 제거

.potRecruitmentDeadline(...)가 두 번 설정됩니다(라인 49, 58). 의미적 문제는 없지만 유지보수성 저하 요소이므로 하나를 제거하세요.

가능한 수정:

                 .potEndDate(pot.getPotEndDate())
-                .potRecruitmentDeadline(pot.getPotRecruitmentDeadline())
                 .potLan(pot.getPotLan())
                 .potStatus(pot.getPotStatus())
                 .applied(isApplied)
@@
                 .isSaved(isSaved)
-                .potRecruitmentDeadline(pot.getPotRecruitmentDeadline())
+                .potRecruitmentDeadline(pot.getPotRecruitmentDeadline())

(중복되는 둘 중 하나를 삭제)

src/main/java/stackpot/stackpot/pot/converter/PotConverter.java (2)

75-76: 닉네임 접미사 공통화 권장

다른 컨버터와 동일하게 " 새싹" 하드코딩을 공통 상수/유틸로 치환해 변경 용이성을 높여 주세요.

-                .userNickname(user.getNickname() + " 새싹")
+                .userNickname(user.getNickname() + UserDisplayConstants.NICKNAME_SUFFIX)

---

65-85: 메서드명 오타(toPrviewDto) — 호환성 고려한 리네이밍 제안

toPrviewDto → toPreviewDto로 정정 권장. 외부 호출점을 고려해 기존 메서드는 @deprecated로 남기고 내부 위임 방식으로 천이하면 안전합니다.

예시:

@Deprecated
public PotPreviewResponseDto toPrviewDto(User user, Pot pot, List<String> recruitmentRoles, boolean isSaved, int potSaveCount, boolean isMember) {
    return toPreviewDto(user, pot, recruitmentRoles, isSaved, potSaveCount, isMember);
}

public PotPreviewResponseDto toPreviewDto(User user, Pot pot, List<String> recruitmentRoles, boolean isSaved, int potSaveCount, boolean isMember) {
    // 기존 구현 내용
}

또한 본 클래스의 toSearchDto는 역할 표시를 RoleNameMapper로 처리하는 반면, 본 메서드는 " 새싹" 접미사를 사용하고 있어 사용자 표시 규칙이 일관되지 않습니다. 표시 규칙을 통합하는 Helper(예: UserDisplayFormatter) 도입을 검토해 주세요.

src/main/java/stackpot/stackpot/feed/service/FeedQueryServiceImpl.java (2)

182-182: 읽기 전용 트랜잭션으로 지정 권장

조회 전용 메서드이므로 readOnly 플래그를 명시해 불필요한 flush/쓰기 지연 등을 방지하는 것이 좋습니다.

-    @Transactional
+    @Transactional(readOnly = true)

---

220-227: series 리스트 null‑세이프 처리 권장

일부 사용자에서 seriesList가 null일 가능성이 있다면 NPE를 유발할 수 있습니다. 방어적 코드를 권장합니다.

예시:

List<String> seriesComments = Optional.ofNullable(targetUser.getSeriesList())
        .orElseGet(Collections::emptyList)
        .stream()
        .map(Series::getComment)
        .toList();

List<String> seriesComments = Optional.ofNullable(user.getSeriesList())
        .orElseGet(Collections::emptyList)
        .stream()
        .map(Series::getComment)
        .toList();

Also applies to: 258-261

src/main/java/stackpot/stackpot/user/converter/UserMypageConverter.java (1)

40-44: seriesComments null-safety 확인 필요

user.getSeriesList()가 null일 경우 NullPointerException이 발생합니다.
엔티티 초기화가 100 % 보장되지 않는다면 NPE 방어 로직을 추가해 주세요.

src/main/java/stackpot/stackpot/search/service/SearchServiceImpl.java (1)

58-61: 예외 무시는 위험합니다

catch (Exception ignored)로 모든 예외를 삼키면 인증 관련 진짜 오류까지 숨겨집니다.
AuthenticationException만 잡고, 그 외 예외는 로깅하거나 재전파하는 편이 안전합니다.

src/main/java/stackpot/stackpot/user/service/UserCommandServiceImpl.java (1)

193-195: 피드 정렬 기준이 없습니다

feedRepository.findByUser_Id(userId) 결과가 정의된 정렬이 없으면 UI 일관성이 깨질 수 있습니다.
OrderByCreatedAtDesc 등의 메서드 명세 또는 Sort 파라미터를 추가해 주세요.

src/main/java/stackpot/stackpot/user/controller/UserController.java (2)

405-426: size 파라미터 검증 추가 권장

현재 size에 상한이 없어 과도한 요청이 가능해집니다.
@Min(1) @Max(100) 등 Bean Validation을 적용해 방어해 주세요.

---

437-443: 동일한 검증 로직 반복

/feeds 엔드포인트도 위와 동일한 size 검증이 필요합니다.
공통 파라미터는 메서드 추출 또는 @Validated DTO로 재사용하면 중복을 줄일 수 있습니다.

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro